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ABSTRACT: There are various SDLC models widely accepted and employed for developing software. 
SDLC models give a theoretical guide line regarding development of the software. Employing proper 
SDLC allows the managers to regulate whole development strategy of the software. Each SDLC has its 
advantages and disadvantages making it suitable for use under specific condition and constraints for 
specified type of software only. We need to understand which SDLC would generate most successful 
result when employed for software development. For this we need some method to compare SDLC 
models. Various methods have been suggested which allows comparing SDLC models. Comparing SLDC 
models is a complex task as there is no mathematical theorem or physical device available. The essence 
of this paper is to analyse some methodologies that could result in successful comparison of the SDLC 
models. For this we have studied various available tools, techniques and methodologies and have tried 
to extract most simple, easy and highly understandable method for comparing SDLC models. 
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I. Introduction 

The System Development Life Cycle framework provides a sequence of activities for system designers 
and developers to follow for developing software. Understanding the basic concepts of software development 
methodologies is necessary to enable evaluation of best software development life cycle (SOFTWARE 
DEVLOPMENT LIFE CYCLE) methodology. All software projects go through the phases of requirements 
gathering, business analysis, system design, implementation, and quality assurance testing[l]. Employing any 
SDLC model is often a matter of personal choice entirely dependent on the developer. Each SDLC has its 
strengths and weaknesses, and each SDLC may provide better functionalities in one situation than in another. 
SDLC models vary greatly in their scope, end-user involvement, risk assessment, and quality control. Then 
there arises the question which model will provide what functionalities and under what expectations. One life 
cycle model theoretically may suite particular conditions and at the same time other model may also looks 
fitting into the requirements but one should consider trade-off while deciding which model to choose[2]. 

II. Phases Involved In SDLC Model 

The phases that are generally present in each and every software development life cycle model are; 

1. Understanding the problem (through requirements gathering). 

2. Deciding a plan for a solution (Designing) 

3. Coding the planned solution 

4. Testing the actual program 

5. Deployment & maintenance of the product. 

For large systems, each activity can be extremely complex and methodologies and procedures are 
needed to perform it efficiently and correctly. Furthermore, each of the basic activities itself may be so large 
that it cannot be handled in single step and must be broken into smaller steps. For example, design of a large 
software system is always broken into multiple, distinct design phases, starting from a very high level design 
specifying only the components in the system to a detailed design where the logic of the components is 
specified. 
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The common phases of an SDLC can be represented by the following diagram. 
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FIGURE l.Phases of an SDLC model. 



In addition to the activities performed during software development, some activities are performed 
after the main development is complete. There is often an installation phase, which is concerned with actually 
installing the system on the client’s computer systems and then testing it. Maintenance is an activity that 
commences after the software is developed. Software needs to be maintained not because some of its 
Components “wear out” and need to be replaced, but because there are often some residual errors remaining in 
the system which must be removed later as they are discovered. Therefore, maintenance is unavoidable for 
software systems. 



III. Commonly Used Models 

The discovery, design, development and delivery of information systems are often linked together in a 
process labelled the Systems Development Life Cycle (SDLC). There are different models which follow these 
basic steps like Waterfall, Prototyping, Spiral, Iterative and incremental development, Agile development, 
Rapid, Rapid prototyping. Evolutionary Model. In this paper we are describing only three of them which are 
mostly used. 

A. Waterfall Model 

Waterfall model was proposed by Royce in 1970 which is a linear sequential software development 
life cycle (SDLC) model. The various phases followed are requirements analysis, design, coding, testing and 
implementation in such a manner that the phase once over is not repeated again and the development does not 
move to next phase until and unless the previous phase is completely completed. The waterfall model is a 
sequential design process, often used in software development processes, in which progress is seen as flowing 
steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, 
Construction, Testing, Production/Implementation and Maintenance[3]. 

B. Incremental Model 

Incremental model is the advancement of the waterfall model. The phases of waterfall model are 
employed in such a manner that the result of any of the increment is used back as the input for the next 
increment. Thus with each increment there are some client's feedback that is used in getting the next 
incremental product. Thus with each ongoing increment the functionality of the core product gets enhanced. 
The incremental Model is an evolution of the waterfall model, where the waterfall model is incrementally 
applied. The series of releases is referred to as — increments || , with each increment providing more 
functionality to the customers. After the first increment, a core product is delivered, which can already be used 
by the customer. Based on customer feedback, a plan is developed for the next increments, and modifications 
are made accordingly. This process continues, with increments being delivered until the complete product is 
delivered [4]. 

C. Spiral Model 

The spiral model[2,5,6] was defined by Barry Boehm in his 1988 article A Spiral Model of Software 
Development and Enhancement. This model was not the first model to discuss iterative development, but it 
was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 
6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) 
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reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with 
an eye toward the end goal of the project. The different phases of spiral model are widely used for industrial 
real word complex software. This is the most advantageous and practical model of all the SDLC models. The 
whole model is an iterative spiral steps that is continuously repeated over and over time to generate the actual 
software components with each spiral. Thus help in reducing the complexity of the software being developed. 
The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral 
model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly 
passes through these phases in iterations (called Spirals in this model). The baseline spirals, starting in the 
planning phase, requirements are gathered and risk is assessed. Each subsequent spiral builds on the baseline 
spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is 
undertaken to identify risk and alternate solutions 

IV. New Proposed SDLC Model 

The new proposed model is developed by incorporating Release Management within the scope of the 
SDLC basic phases like analysis, design, coding, testing and maintenance. 

Release Management is the concept which is quite new in the field of Software Engineering. The 
concept of release management derives itself from the core concept of project management employed in 
Software Engineering. Software how-so-ever efficient and effective cannot be considered commercially 
successful until and unless the software remains in the market for sufficiently long duration, in order to recover 
the cost that incurred during development and deployment of the software. 

The release management [7] process is a relatively new but rapidly growing discipline within 
software engineering of managing software releases. As software systems, software development processes, and 
resources become more distributed, they invariably become more specialized and complex. Furthermore, 
software products (especially web applications) are typically in an ongoing cycle of development, testing, and 
release. Add to this an evolution and growing complexity of the platforms on which these systems run, and it 
becomes clear there are a lot of moving pieces that must fit together seamlessly to guarantee the success and 
long-term value of a product or project. The need therefore exists for dedicated resources to oversee the 
integration and flow of development, testing, deployment, and support of these systems. Although project 
managers have done this in the past, they generally are more concerned with high-level, "grand design" 
aspects of a project or application, and so often do not have time to oversee some of the more technical or day- 
to-day aspects. Release managers (aka "RMs") address this need. They must have a general knowledge of every 
aspect of the software development process, various applicable operating systems and software application or 
platforms, as well as various business functions and perspectives. 

V. Most Commonly Used Tools/Techniques For Comparing SDLC Models 

To analyze a particular SDLC model and compare it with some of the existing model is only and only 
possible by employing any available tool, technique or method and deducing some mathematical result. This is 
extremely difficult and controversial as the SDLC model themselves are not mathematical models but are 
purely theoretical model that provides only the concept of how and what should be the methodology that must 
be employed for developing some specific software. The SDLC may vary for similar type of software depending 
on the developing organization, client organization, and available resources, expertise level of the developers 
and many other factors. Say for example: Let us assume there is software to be developed that must be able to 
generate payroll. Now if the organization for which the software is being developed is extremely small say 
about 10 employees then we can use waterfall model for developing the software. But in -case the client 
organization is extremely large having 100000 employees and multiple disciplines then there must be slight 
variation in the software being developed in accordance to the various departments. For such client the best 
suited SDLC will be incremental model or RAD depending upon similarities and differences among the need 
and requirement of the client organization. Any employed software must have following characteristics: 

1. effective 

2. efficient 

3. reliable 

4. time saving 

5. effort saving 

6. cost saving 

7. longer product life 
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C. Merant Tracker 

Merant Tracker] 1 0] automates the capture, management and communication of issues across project 
teams in development and non -development projects alike. Merant delivers the industries most flexible and 
comprehensive enterprise change management solutions. Already in use at thousands of organizations across 
the globe, Merant‘s products and services dramatically enhance the productivity, quality and ROI of customers 1 
technology initiatives by allowing them to quickly and cost-effectively track, manage and control modifications 
in business-critical information assets. 

D .PQMPlus 

PQM Plusfll] is the Intelligent Software Measurement and Estimating Tool. It is a 
productivity/quality measurement system developed for software development project managers and 
measurement specialists. PQM Plus is a benchmarking and measurement tool with a robust function point 
repository that provides project estimating based on historical data, project scheduling, and risk assessments. 
PQM Plus and SMR have been designed to work together to share relevant data to aid in the production of 
software measurement reports. PQM Plus has received Type 1 and Type 2 certification from IFPUG, and is the 
only measurement tool available today that has received this level of certification. IFPUG Type 2 Certification 
requires PQM Plus be an "Expert system that aids in the counting of function points." 

E. SMR 

Software Measurement, Reporting and Estimating (SMR) [12] are a tool that automates software 
project estimating and the reporting of project performance metrics. Organizations can use SMR to estimate 
project size, effort, schedule and staffing early in the life-cycle using in-house and/or industry benchmarks. 
Once the project is complete SMR is used to capture project data, report the performance of development 
projects, and compare the performance to in-house and/or industry benchmarks. SMR's intuitive interface 
allows a user to quickly develop project estimates, enter key project statistics, compare the performance to 
benchmarks, analyze the results of the comparisons, and publish the report in either Word or Power Point 
formats. SMR has been designed to work with PQM Plus and the Function Point WORKBENCH in order to 
share relevant data to aid in the production of software measurement reports. 

F. WORKBECNCH 6.0 

The Function Point WORKBENCH] 12] is a network-ready Windows-based software tool which 
makes it easy for an organization to implement the Function Point Analysis technique for sizing, estimating, 
and evaluating software. The Function Point WORKBENCH is specifically designed to be sale-able for 
effective use by individual counters as well as for large distributed IT environments. The Function Point 
WORKBENCH™ and SMR have been designed to work together to share relevant data to aid in the 
production of software measurement reports. 

G. Putnam Model 

The Putnam model is an empirical software effort estimation model [13]. The original paper by 
Fawrence H. Putnam published in 1978 is seen as pioneering work in the field of software process 
modeling[14]. As a group, empirical models work by collecting software project data (for example, effort and 
size) and fitting a curve to the data. Future effort estimates are made by providing size and calculating the 
associated effort using the equation which fit the original data (usually with some error). 

Created by Lawrence Putnam, Sr. the Putnam model describes the time and effort required to finish a software 
project of specified size. SLIM (Software Life-cycle Management) is the name given by Putnam to the 
proprietary suite of tools his company QSM, Inc. has developed based on his model. It is one of the earliest of 
these types of models developed, and is among the most widely used. Closely related software parametric 
models are Constructive Cost Model (CoCoMo), Parametric Review of Information for Costing and Evaluation 
- Software (PRICE-S), and Software Evaluation and Estimation of Resources - Software Estimating Model 
(SEER-SEM). 

H. QSM-SLIM 

SLIM-Estimate[15] helps you estimate the cost, time, and effort required to satisfy a given set of 
system requirements and determine the best strategy for designing and implementing your software or systems 
project. In addition to software cost estimation, this powerful systems and software project estimation tool 
provides a high level of configurability to accommodate the different design processes being used by developers 
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today: such as Agile development, package implementation, hardware, call center development, infrastructure, 
model-based development, engineering and architecture design, service-oriented architecture, SAP, Oracle, 
and more. 

I. COCOMO Models 

The software cost estimation model this report will focus on is the Constructive Cost Model, also 
known as CoCoMo. It was developed in 1981 by Barry Boehm. Boehm proposed three levels of the model; 
basic, intermediate, detailed. We have chosen to use the intermediate level for our cost estimation model. 
CoCoMo model distinguishes between three modes of software development and provides different cost and 
schedule equation for each mode. It produces the order-of-magnitude assessment of the expected development 
costs. 



VI. Use Of COCOMO Model For Comparing Different SDLC Models 

COCOMO (constructive cost model) is empirical cost estimation model that is self sufficient in 
providing some what a clear picture in mathematical terms regarding the software being developed. CoCoMo 
was initially proposed by Dr. Barry W Boehm in year 1981. The model calculates the cost in terms of the 
effort, development time and the staffing needs. Various other derivatives of CoCoMo 81 (as proposed by 
Barry Boehm) are CoCoMo-II, COSYSMO, etc. The Constructive Cost Model (CoCoMo) [16] is an algorithmic 
software cost estimation model developed by Barry W. Boehm. The model uses a basic regression formula with 
parameters that are derived from historical project data and current project characteristics. 

CoCoMo was first published in Boehm's 1981 book Software Engineering Economics[17] as a model for 
estimating effort, cost, and schedule for software projects. It drew on a study of 63 projects at TRW Aerospace 
where Boehm was Director of Software Research and Technology. The study examined projects ranging in size 
from 2,000 to 100,000 lines of code, and programming languages ranging from assembly to PL/I. These 
projects were based on the waterfall model of software development which was the prevalent software 
development process in 1981. 

References to this model typically call it CoCoMo 81. In 1995 CoCoMo II was developed and finally 
published in 2000 in the book Software Cost Estimation with CoCoMo II. [18] CoCoMo II is the successor of 
CoCoMo 81 and is better suited for estimating modern software development projects. It provides more support 
for modern software development processes and an updated project database. The need for the new model came 
as software development technology moved from mainframe and overnight batch processing to desktop 
development, code re-usability and the use of off-the-shelf software components. This article refers to CoCoMo 
81. 

CoCoMo consists of a hierarchy of three increasingly detailed and accurate forms. The first level, 
Basic CoCoMo is good for quick, early, rough order of magnitude estimates of software costs, but its accuracy 
is limited due to its lack of factors to account for difference in project attributes (Cost Drivers). Intermediate 
CoCoMo takes these Cost Drivers into account and Detailed CoCoMo additionally accounts for the influence of 
individual project phases. 



VII. Conclusion 

The above study gives a clear understanding that various SDLC models when employed for 
developing different software then they may generate successful results owing to the fact that circumstances, 
resources, requirements, etc do vary for developer side as well as for client side. Employing a specified SDLC 
model for certain type software could not be determined in exact terms. Employing of any SDLC model is 
entirely a matter of choice which is dependent on the developer side. Thus comparing any of the SDLC models 
on some mathematical basis is almost impossible; they could be compared only on theoretical basis. But if we 
do want to compare SDLC models mathematically then we need to develop the same software with same 
requirements and same developer expertise.We need to keep all the elements involved in the development of 
the software constant except for the SDLC model. Out of many SDLC models the best suited is entirely 
dependent on developer end and client end constraints. If we develop software using multiple SDLC model 
then the only method to compare SDLC models used in them with success will primarily depend upon LOC 
(lines of codes). The most simple and easiest mathematical model for generating an estimation of effort, 
development time and staffing is CoCoMo - 81. Employing CoCoMo - 81 will enable us to get somewhat a 
theoretical view displayed in mathematical form which SDLC model is more satisfactory successful for 
developing specified software. 
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There are many SDLC models such as. Waterfall, RAD, spiral, incremental, V-shaped etc. used in 
various organizations depending upon the conditions prevailing there. All these different software development 
models have their own advantages and disadvantages. In the Software Industry, the hybrid of all these 
methodologies is used i.e with some modification. In this paper we have compared the different software 
development life cycle models on the basis of certain features like- Requirement specifications, Risk 
involvement. User involvement, Cost etc. on the basis of these features for a particular software project one can 
decide which of these software development life cycle models should be chosen for that particular project. 
Selecting the correct life cycle model is extremely important in a software industry as the software has to be 
delivered within the time deadline & should also have the desired quality. This study will make the process of 
selecting the SDLC model easy& hence will prove to be very effective for software industry. 
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